Add OpenTelemetry v2 integration with enhanced features and comprehensive testing#1314
Add OpenTelemetry v2 integration with enhanced features and comprehensive testing#1314tconley1428 merged 35 commits intomainfrom
Conversation
This commit adds a new OpenTelemetry interceptor (opentelemetryv2) with enhanced capabilities for Temporal workflow integration: Features: - Deterministic ID generation for spans/traces in workflows using TemporalIdGenerator - Context propagation across workflow and activity boundaries - Support for workflow-level span creation via workflow.start_as_current_span - Enhanced interceptor with context propagation to activities and nexus operations - Compatible with existing opentelemetry module while providing additional functionality Implementation: - New TemporalIdGenerator uses workflow.random() for deterministic IDs in workflows - TracingInterceptor handles client, worker, activity, workflow, and nexus operations - Workflow-safe span creation context manager in workflow module - Comprehensive test coverage for trace propagation scenarios This is separate from the OpenAI agents OTEL integration and provides general-purpose OpenTelemetry improvements for Temporal workflows. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
…inting fixes This commit significantly improves the OpenTelemetry v2 integration for the Temporal SDK with the following enhancements: ## Core Features Added: - **Comprehensive test coverage**: Added `test_opentelemetryv2_comprehensive_tracing` covering all workflow operations including activities, local activities, child workflows, timers, signals, updates, queries, and Nexus operations - **Read-only mode detection**: Implemented `workflow.unsafe.is_read_only()` to prevent span ID generation errors during queries and update validators - **Test isolation**: Added pytest fixture to reset OpenTelemetry tracer provider state between test runs - **Span hierarchy validation**: Refactored tests to use `dump_spans()` hierarchy validation for better maintainability ## Linting and Documentation: - Fixed all import path issues for OpenTelemetry ID generators - Added comprehensive docstrings for all public classes and methods - Fixed type annotations and null handling throughout the codebase - Resolved Nexus headers access issues with proper type protocols - Achieved complete pydocstyle compliance ## Technical Improvements: - Enhanced `TemporalSpanProcessor` with proper replay handling - Improved `TemporalIdGenerator` with deterministic workflow-safe random generation - Updated span parenting validation to ensure proper trace relationships - Added max_cached_workflows=0 to all test workers for deterministic behavior 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
…rovider in a workflow will use a replay safe version. Care should still be taken if creating one from scratch inside a workflow
cretz
left a comment
There was a problem hiding this comment.
Just a couple of minor things now...
…nterceptors if not present in the worker's client
THardy98
left a comment
There was a problem hiding this comment.
walked through it with tim lgtm
| if interceptors is not None: | ||
| config["interceptors"] = interceptors | ||
|
|
||
| # Only propagate client interceptors if they are provided as a simple list (not callable) |
There was a problem hiding this comment.
I don't think you should propagate client plugins to workers, that is what our system does. Plugins should just provide the values that would be set for those two objects IMO. But we can discuss this. Maybe we just need a general interceptors option on simple plugin that is smart enough to check interceptor type and prevent double-register?
There was a problem hiding this comment.
I don't think you should propagate client plugins to workers, that is what our system does.
If you register it on the client, which isn't guaranteed.
Maybe we just need a general interceptors option on simple plugin that is smart enough to check interceptor type and prevent double-register?
Maybe. With this change that's functionally the same as just providing them to client_interceptors, but might be less confusing for implementors.
Summary
This PR introduces a new OpenTelemetry v2 integration for the Temporal Python SDK with significant enhancements over the existing OpenTelemetry support. The integration provides deterministic tracing, comprehensive test coverage, and improved maintainability.
Key Features Added:
SimplePluginbase classtemporalio.contrib.opentelemetryv2.workflow.start_as_current_span()for user workflow tracingArchitecture Improvements:
TemporalSpanProcessorskips span export during workflow replay to prevent duplicate telemetryworkflow.unsafe.is_read_only()to handle queries and update validators safelyTracingInterceptorcovering all client and worker operationsTesting & Quality:
test_opentelemetryv2_comprehensive_tracingcovering all workflow operations with proper span hierarchy validationdump_spans()for maintainable hierarchy validation similar to existing OpenTelemetry testsTest plan
add_temporal_spans=False) and comprehensive tracing (add_temporal_spans=True)🤖 Generated with Claude Code